-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
support for python 3.5/3.8 and django 2.2 + basic tests #4
Conversation
@pmitros would you mind giving me some permissions on this repo so I can activate GitHubActions and be able to merge and tag a release? |
@OmarIthawi You should have a request to become a collaborator. I just followed up by email as well. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me. Please review comment and proceed as you see fit. Thank you for the contribution!
requirements.txt
Outdated
XBlock==1.2.1; python_version < '3' | ||
XBlock==1.4.0; python_version >= '3' | ||
|
||
xblock-sdk==0.2.2 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Stylistically, I'm not a big fan of locking versions. I'm willing to defer to your lead here, but my preference is >= rather than == for Python 3 versions wherever possible.
Rationale:
-
For development/sandbox/non-deployment settings, I prefer to get the latest version, and fix bugs when and if they occur. Otherwise, you end up with piling debt, and major ports. If you develop with a range of versions, code tends to run up fewer version dependencies.
-
For deployment, I like stable configurations, but I assume versions will come from the install of edX platform. Indeed, locking versions can make a mess if one release of edX wants 1.15 of something, another wants 1.13, and the XBlock is at a loss for which one to lock to.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like this approach. I can actually go with unlocked versions and it won't be bad, except for Python 2.7 compatibility which I like to preserve for a while.
Looks good to me! |
I've added support for python 3.5/3.8 and django 2.2 so this XBlock is compatible with the Juniper release.
TODO
master
before merging (for pre-Juniper open edx releases)tox.ini
# 58, 228-229, 250, 279-288, 307-317, 330-363, 373, 391-396
fromtox.ini
$ pip install https://github.com/appsembler/FeedbackXBlock/archive/omar/py3.tar.gz
master
after merge (for Juniper)Stretch Goals